精华内容
下载资源
问答
  • 理解基于 TCP应用层通信协议

    千次阅读 2019-07-10 18:08:17
    关于七网络通信的基本原理,特别推荐这篇图文并茂的长文《TCP/IP笔记 - 综述》 TCP 通信基本特征 TCP数据流 特征 1. 消息(结构化数据)被编码成字节流写入 TCP 通道。 2. TCP 通道不能保证字节流一定...

    TCP 协议示意

     

    TCP协议

    关于七层网络通信的基本原理,特别推荐这篇图文并茂的长文《TCP/IP笔记 - 综述》

    TCP 通信基本特征

     

    TCP数据流

    特征

    1. 消息(结构化数据)被编码成字节流写入 TCP 通道。

    2. TCP 通道不能保证字节流一定到达目的地,但能保证到达的字节流是 正确有序 的。对于发送端而言,可以不停的写入数据,当网络出问题 ACK 超时会报错,但由于缓存的存在,发送端其实不知道有多少数据到达接收端。对于接收端而言,一直等待接收数据,一旦收到数据是能确定这些数据是连续、有序的,中间不可能有数据缺失,但接收端无法知道何时能收到下一个数据包。

    3. TCP 通道像一个无形的管道,这个管道的流量由全链路复杂的网络环境决定,TCP 协议会自动调节(即拥塞控制)。

    4. TCP 是全双工协议,读写互不干扰。注意,如图所示,读写是两个完全不同的通道,它们完全可能走不同的物理链路。

    TCP控制流程

    疑问

    1. 对于接收端来说,虽然能接收到正确的有序的字节流,如何界定收到的字节流构成一个完整的消息体?这就是所谓 “”粘包” 问题。

    2. 对于接收端来说,一直在等待读取数据,如何判断发送端是空闲还是失联?这就是 超时问题。

    基于 TCP 构建数据通信协议,首先要解决的就是上面两个问题。另外,不管是客户端还是服务端,它们都同时是发送端和接收端。从应用层面来说,我们还需要构建 请求(Request)/响应(Response) 机制,比如浏览器调用后端 API 服务需要知道结果,或者消息服务器往客户端推送消息需要知道消息是否被客户端处理。当然也有一种消息从发送端发出后是不需要知道结果的,这种消息通常称为 通知(Notification)

    基于 TCP 协议构建应用层的通信协议

    两个模式和三个问题

    TCP 协议本质是流模式,基于它可以构建各种应用层通信协议,但其基本模式只有两种:

    1. Streaming 流模式,如 HTTP/1 协议,redis 协议。

    2. Multiplexing 多路复用模式,如 MongoDB 协议、常见的 RPC 协议。

    随着技术的发展,也出现了这两种基本模式的混合体:

    1. Streaming + Multiplexing,如基于 HTTP/1 实现的 JSON-RPC 协议。

    2. Multiplexing + Streaming,如 HTTP/2,基于 HTTP/2 的 gRPC 等。

    根据 TCP 协议的特征,我们应用层协议一般要解决三个问题:

    1. 粘包问题,从字节流中分解出一个个独立的消息体;

    2. 请求/响应机制;

    3. 消息指令或类型定义,解决超时问题和实际应用的通信需求。

    Streaming

    最原始的 Streaming 模式就是一应一答模式。

    相信不少人基于 TCP 开发网络通信时干过这种事:把一个请求数据变成字节写入 TCP,再等待对方的应答数据,收到应答后开始下一个请求。HTTP/1.0 就是这个模式的最典型。

    用上面的管道示意图来理解,每次往管道放入一个数据包,然后等对方回复一个数据包,从而实现应用层需要的 请求(Request)/响应(Response) 机制。

    这种模式下通信效率显然特别低,为了提升效率得开多个 TCP 通道,然而打开 TCP 通道不但有三次握手开销,还给服务器带来一定资源开销压力,特别是 Apache 那种传统的 web 服务。

    既然是管道,其实是可以像流体一样不断的写入数据包,只要定义 请求(Request)/响应(Response) 的逻辑关系,这就是 Pipelining 机制,HTTP/1.1 和 redis 协议属于这种模式。

    流水线请求应答模式

    比如 HTTP/1.1 协议,允许客户端依次写入多个请求而无需等待应答,服务端则应该按照客户端的请求顺序依次进行响应,从而确保 请求(Request)/响应(Response) 一一对应。

    HTTP/1

    HTTP/1 是基于文本的协议:

    1. 通过 CRLF (也就是 \r\n) 标志解决粘包问题,如果内容中有 \r\n,必须进行转义,第一行命令行、Headers 头部和实体主体各有不同的转义处理。

    2. 请求/响应机制就是一应一答模式或者 Pipelining。

    3. 第一行定义了丰富的消息类型,超时机制则是在浏览器或者服务端逻辑实现,协议层没有定义。

    HTTP 请求协议

     

    HTTP 响应协议

    Redis 的 RESP 协议

    RESP 也是基于文本的协议:

    1. 定义了五种消息类型,分别由 +-:$* 字符开头,CRLF 结尾,其中 Bulk Strings 类型允许包含 CRLF。

    2. 请求/响应机制是复杂的 Pipelining,允许客户端不断的写入请求,服务端会按照顺序响应请求。但是,根据请求命令的不同,对应响应体会有 零到无数 个。

    3. 协议层定义了五种消息类型,其中的 Arrays 是结构化消息类型。对比 HTTP 协议,RESP 协议不用依赖于更上一层的 JSON、XML 协议等,就能构造出复杂的消息体。超时问题依然由客户端或服务端的逻辑实现。

    RESP 协议

    HTTP/1 协议和 RESP 协议可以算是我们当前使用最广泛的协议,有很多服务都是基于 RESP 协议。然而,即便应用最广,也有 Pipelining 机制,基于 Streaming 的协议依然有一个痛点:头部阻塞,也就是如果某一个请求需要消耗很长处理时间才能响应,后续响应都得排队等候,即被阻塞。

    Multiplexing

    这是一种解决头部阻塞问题的更高效的模式,它不在依赖于 请求(Request)/响应(Response) 的顺序处理,允许请求并发发出,请求处理完成就立即响应,其核心就是 Request ID

     

    Multiplexing

    MongoDB 协议

    MongoDB 协议 是基于二进制的协议,协议定义的内容很丰富:

    1. 一个完整消息由 Header 和 Body 组成。Header 有 16 位,定义如下,Body 的长度则在 Header 中的 messageLength 定义,编码格式则是 bson。

    2. Header 中的 requestID 是请求 ID,responseTo 是响应 ID,所以其请求/响应机制是Multiplexing。

    3. Header 中的 opCode 定义了 11 中消息类型:

    struct MsgHeader {

      int32  messageLength; // total message size, including this

      int32  requestID; // identifier for this message

      int32  responseTo; // requestID from the original request

      int32  opCode; // request type - see table below

    }

    Opcode 表:

    | Opcode Name | Value | Comment |

    |----------|-------|--------------|

    | OP_REPLY | 1 | Reply to a client request. responseTo is set. |

    | OP_MSG | 1000 | Generic msg command followed by a string. |

    | OP_UPDATE | 2001 | Update document. |

    | OP_INSERT | 2002 | Insert new document. |

    | RESERVED | 2003 | Formerly used for OP_GET_BY_OID. |

    | OP_QUERY | 2004 | Query a collection. |

    | OP_GET_MORE | 2005 | Get more data from a query. See Cursors. |

    | OP_DELETE | 2006 | Delete documents. |

    | OP_KILL_CURSORS | 2007 | Notify database that the client has finished with the cursor. |

    | OP_COMMAND | 2010 | Cluster internal protocol representing a command request. |

    | OP_COMMANDREPLY | 2011 | Cluster internal protocol representing a reply to an OP_COMMAND. |

    注意,只有 OP_QUERY 和 OP_GET_MORE 两种类型有 requestID,其它类型都没有!

    所以,在 MongoDB 2.6 之前,写入、更新、删除操作等是没有响应结果的!那么如何确定写入是否成功呢?通过 getLastError 命令,这个命令是基于 OP_QUERY 的。每一个写入操作追加一个 getLastError 请求,查询上一次命令是否报错(很笨的设计有没有?相当于回退到一应一答的 Streaming 模式了)。

    MongoDB 2.6 之后使用了 maxWireVersion 3 协议,扩展了数据库的 commands,可以进行各种各样的操作,可以在客户端使用 db.$command.help() 查看所有命令。而 commands 的本质就是 OP_QUERY 类型的查询,所以第三代协议相当于只使用 OP_QUERY 、OP_GET_MORE和 OP_REPLY 类型的消息,淘汰了其它类型。

    TiKV 协议

    TiKV 协议 是基于二进制的协议:

    1. 一个完整消息由 Header 和 Body 组成。Header 有 16 位,定义如下,Body 的长度则在 Header 中的 payload_len 定义,编码格式由 protobuf 定义。

    2. Header 中的 msg_id 是请求 ID,所以其请求/响应机制是 Multiplexing

    3. 没有定义消息类型,消息类型由 protobuf 精确定义

    struct MsgHeader {

      uint16  MSG_MAGIC; // const MSG_MAGIC: u16 = 0xdaf4;

      uint16  MSG_VERSION_V1; // const MSG_VERSION_V1: u16 = 1;

      uint32  payload_len; // Body length

      uint64  msg_id; // request ID

    }

    Streaming + Multiplexing

    这种模式是由 JSON-RPC 2.0 specifications 出现引发的,很多人基于 HTTP 来实现 JSON-RPC 服务。

    JSON-RPC 2.0

    JSON-RPC 2.0 定义两类四种类型的消息,分别是:

    1. Request object:

    定义了 jsonrpcmethodparamsid 四种属性,当 id 存在时,则为标准的 Request,如

    {"jsonrpc":"2.0","method":"subtract","params": [42,23],"id":1}

    Request 需要对方进行响应;不存在时则为 Notification,如

    {"jsonrpc":"2.0","method":"update","params": [1,2,3,4,5]}

    Notification 不需要对方响应。

    2. Response object:

    包括 jsonrpcresulterrorid 四种属性,id 必须存在,resulterror 只能有一个存在,当 result 存在时,则为 Success Response,如

    {"jsonrpc":"2.0","result":19,"id":1}

    当 error 存在时,则为 Error Response,如

    {"jsonrpc":"2.0","error":{"code":-32601,"message":"Method not found"},"id":"5"}

    另外也有 RESP 协议配合 JSON-RPC 2.0 实现的 RPC 框架 toa-net,主要是利用 RESP协议解决粘包问题,JSON-RPC 2.0 协议解决 Multiplexing 模式的 请求(Request)/响应(Response)

    Multiplexing + Streaming

    HTTP/2

    HTTP/2 协议在一个 TCP 通道建立了 N 个 Stream 流通道,每个 Stream 有唯一的 ID,从而实现 Multiplexing 模式,Stream 内则与原来的 HTTP/1 一样,是 Streaming 模式。

    HTTP/2

    展开全文
  • TCP应用层协议

    千次阅读 2019-03-23 17:59:17
    TCP/IP是个协议组,可分为三个层次:网络层、传输层和应用层。 在网络层有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议。 在传输层中有TCP协议与UDP协议。 在应用层有FTP、HTTP、TELNET、SMTP、DNS等协议。 1....

    TCP/IP是个协议组,可分为三个层次:网络层、传输层和应用层。
    在网络层有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议。
    在传输层中有TCP协议与UDP协议。
    在应用层有FTP、HTTP、TELNET、SMTP、DNS等协议。

    • 1.HTTP(超文本传输协议) 我们平常的浏览网页

    1)默认使用80端口
    2)一般用于浏览网页,因此没有权限问题,谁都可以访问
    3)一般使用txt文本传输(文本,声音,动画,图片等)
    4)它是TCP的应用层协议
    5)传输速度快

    • 2.FTP(文本传输) 远程控制电脑

    1)默认使用21端口
    2)一般用于C/S模式,需要账号和密码登录
    3)主要用于文件的批量处理
    4)它比HTTP协议更早出现,它TCP的传输层协议

    3.HTTPS
    1)默认使用443端口
    2)它与http类似但它有加密传输,使用SSL+HTTP模式进行传输

    展开全文
  • 基于TCP/UDP的应用层协议

    万次阅读 2018-05-21 19:10:48
    1,基于TCP的有: Telnet(Teletype over the Network, 网络电传) ,通过一个终端(terminal)登陆到网络 FTP(File Transfer Protocol, 文件传输协议) ,由名知义 SMTP(Simple Mail Transfer Protocol,简单邮件传输...

    1,基于TCP的有:
    Telnet(Teletype over the Network, 网络电传) ,通过一个终端(terminal)登陆到网络
    FTP(File Transfer Protocol, 文件传输协议) ,由名知义
    SMTP(Simple Mail Transfer Protocol,简单邮件传输协议) ,用来发送电子邮件
    POP3(Post Office Protocol 3)邮件读取协议,协议通常被用来接收电子邮件
    HTTP
    HTTPS

    2,基于UDP的有:
    NFS(网络文件系统)
    TFTP
    SNMP(Simple Network Management Protocol, 简单网络管理协议) ,用于网络信息的收集和网络管理
    DHCP
    NTP(Network Time Protocol,网络时间协议) ,用于网络同步
    BOOTP(Boot Protocol,启动协议) ,应用于无盘设备
    3,基于UDP和TCP的有:
    DNS(Domain Name Service,域名服务) ,用于完成地址查找,邮件转发等工作
    ECHO(Echo Protocol, 回绕协议) ,用于查错及测量应答时间

    展开全文
  • 参考:https://zhidao.baidu.com/question/337954440.html 基于TCP的有FTP、Telnet、SMTP、HTTP、POP3与DNS 基于UDP的有TFTP、SNMP与DNS 其中DNS既可以基于TCP,也可以基于UDP。

    参考:https://zhidao.baidu.com/question/337954440.html
    基于TCP的有FTP、Telnet、SMTP、HTTP、POP3与DNS
    基于UDP的有TFTP、SNMP与DNS
    其中DNS既可以基于TCP,也可以基于UDP。

    展开全文
  • 基于TCP应用层协议 与基于UDP的应用层协议分别有哪些
  • 一、基于TCP应用层协议有:SMTP、TELNET、HTTP、FTP 基于UDP的应用层协议:DNS、TFTP(简单文件传输协议)、RIP(路由选择协议)、DHCP、BOOTP(是DHCP的前身)、IGMP(Internet组管理协议) ...
  • 常见的基于TCP或UDP的应用层协议

    千次阅读 2020-07-09 16:00:22
    基于TCP应用层协议有:SMTP、TELNET、HTTP、FTP 基于UDP的应用层协议:DNS、TFTP(简单文件传输协议)、RIP(路由选择协议)、DHCP、BOOTP(是DHCP的前身)、IGMP(Internet组管理协议)
  • 常见应用层协议都是基于什么运输层协议的 TCP:HTTP,FTP,SMTP,TENET,POP3,Finger,NNTP,IMAP4, UDP:BOOTP,DHCP,NTP,TFTP,SNMP DNS可以基于udp也可以基于TCP
  • TCP应用层主要协议

    千次阅读 2015-09-27 21:51:05
    TCP/IP应用层对应了OSI参考模型的上三层(会话层、表示层和应用层),它包括了一些服务。 这些服务是与终端用户相关的认证、数据处理及压缩,应用层还要告诉传输层哪个数据流 是由哪个应用程序发出的。应用层主要...
  • 应用层协议 在传输层之上,便是应用层。传输层的UDP报文和TCP报文段的数据部分就是应用层交付的数据。 不同类型的网络应用有不同的通信规则,因此应用层协议都是多种多样的,比如DNS、FTP、Telent、SMTP、HTTP、RIP...
  • TCP /IP 协议-应用层协议

    千次阅读 2016-07-03 16:01:34
    应用层协议在传输层之上,便是应用层。传输层的 UDP 报文和 TCP 报文段的数据部分就是应用层交付的数据。不同类型的网络应用有不同的通信规则,因此应用层协议是多种多样的,比如 DNS、FTP、Telnet、SMTP、HTTP、RIP...
  • HTTP协议:简单对象访问协议,对应于应用层 ,HTTP协议是基于TCP连接的 http是基于tcp协议的, TCP/IP是传输层协议,主要解决数据如何在网络中传输;而HTTP是应用层协议,主要解决如何包装数据。...
  • TCP/IP的应用层协议

    千次阅读 2019-03-24 10:38:16
    应用 应用层协议 运输层协议 名字转换 DNS UDP 文件传送 TFTP UDP 路由选择协议 RIP ...
  • 基于tcp应用层协议还原

    千次阅读 2019-01-13 17:39:50
    基于tcp应用层协议还原技术是网络安全每个领域都需要的一种基础技术。 首先,我们需要认识到tcp协议的两个特征: tcp是一种流协议。发送者以字节流的形式传递给接收者。 tcp协议本身没有固有的”报文”或”报文...
  • 基于TCP应用层协议有:POP3、SMTP(简单邮件传输协议)、TELNET(远程登陆协议)、HTTP(超文本传输协议)、HTTPS(超文本传输安全协议)、FTP(文件传输协议) 基于UDP的应用层协议:TFTP(简单文件传输协议)、...
  • TCP/IP协议简介(五) 之 应用层

    万次阅读 2016-07-28 16:02:46
    应用层协议在传输层之上,便是应用层。传输层的 UDP 报文和 TCP 报文段的数据部分就是应用层交付的数据。不同类型的网络应用有不同的通信规则,因此应用层协议是多种多样的,比如 DNS、FTP、Telnet、SMTP、HTTP、RIP...
  • 基于TCP/IP协议簇的安全架构

    千次阅读 2021-10-24 10:48:40
    简单网络管理协议(Simple Network Management Protocol)是专门设计用于在 IP 网络管理网络节点(服务器、工作站、路由器、交换机及HUBS等)的一种标准协议,它是一种应用层协议。 SNMP PGP 优良保密协议(Pretty ...
  • 应用层主要包含的协议有:文件传送协议FTP、超文本传送协议HTTP FTP提供交互式的访问,允许客户指明文件的类型与格式,并允许文件具有存取权限。FTP屏蔽了各计算机系统的细节,因而适合于在异构网络中任意计算机...
  • 应用层协议 --- Telnet协议

    千次阅读 2018-10-26 08:49:48
     Telnet 协议TCP/IP 协议族中的一员,是 Internet 远程登陆服务的标准协议和主要方式,它基于 TCP 协议,使用端口 23。 终端使用者在本地电脑上使用 telnet 程序,用它连接到服务器,终端使用者可以在 telnet...
  • TCP(Transmission Control Protocol,传输控制协议)和UDP(User Datagram Protocol,用户数据报协议)是运输的两个主要协议,均是互联网的正式标准。 TCP: 优点:可靠,稳定TCP的可靠提现在传递数据之前,会有...
  • TCP和UDP是两个传输层协议,广泛应用于网络中不同主机之间传输数据。对任何程序员来说,熟悉TCP和UDP的工作方式都是至关重要的。这就是为什么TCP和UDP是一个流行的Java编程面试问题。我曾经在各种不同的Java面试中见...
  • HTTP协议是什么?是基于tcp、ip协议

    千次阅读 2020-07-20 14:45:53
    本文是自己总结,如有不对,请大家指教,谢谢。。。 Http协议是互联网传输协议:连接客户端与服务端,规范发送(图片,文字,视频)等。其中有多种请求方式,主要有get和post,1...4、http请求是基于tcp/ip的。 ...
  • 基于MQTT应用层协议的物联网家庭温湿度监测系统

    千次阅读 多人点赞 2020-05-07 17:50:31
    总结与展望 这次基于MQTT应用层协议的物联网家庭温湿度监测系统的实验过程中,我查询了很多资料,解决了不少bug。主要锻炼了学习新知识并且运用新知识的能力,在此过程中运用到了嵌入式,服务器前后端等知识。通过...
  • 传输层协议、应用层协议

    千次阅读 2018-05-10 00:17:10
    传输层协议、应用层协议一、传输层协议1、传输层概述 (1)传输层的作用 IP层提供点到点的连接 传输层提供端到端的连接 (2)传输层的协议 TCP(Transmission Control Protocol)传输控制协议 可靠的、面向...
  • TCP/IP,应用层端口,协议数据单元
  • 基于TCP协议,基于UDP的协议

    万次阅读 2015-04-11 13:32:14
    TCP与UDP区别 TCP---传输控制协议,提供的是面向连接、可靠的字节流服务。...UDP---用户数据报协议,是一个简单的面向数据报的运输层协议。UDP不提供可靠性,它只是把应用程序传给IP层的数据报发送出去,但是并不
  • TCP/IP模型之应用层及HTTP协议

    千次阅读 2018-07-25 12:16:19
    应用层的功能 负责应用程序间的沟通来制定协议,通俗的来讲就是应用层会借助TCP、UDP... –基于TCP应用层协议 –基于UDP的应用层协议 *简单电子邮件传输协议(SMTP) *动态主机配置协议(DHCP) *文件...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 191,713
精华内容 76,685
关键字:

基于tcp的应用层协议