TCP / IP 协议

TCP / IP 简介

TCP / IP 协议模型(Transmission Control Protocol/Internet Protocol),包含了一系列构成互联网基础的网络协议,是 Internet 的核心协议。
TCP / IP 不是一个协议,而是一个协议族的统称。里面包括了 IP 协议,IMCP 协议,TCP 协议,以及我们更加熟悉的 http、ftp、rtmp 协议等等。

TCP / IP 协议分层

协议分层
TCP / IP 协议族按照层次由上到下,层层包装。

应用层:

向用户提供一组常用的应用程序,比如电子邮件、文件传输访问、远程登录等。远程登录 TELNET 使用 TELNET 协议提供在网络其它主机上注册的接口。TELNET 会话提供了基于字符的虚拟终端。文件传输访问 FTP 使用 FTP 协议来提供网络内机器间的文件拷贝功能。

具体应用如下
  1. 超文本传输协议(HTTP):万维网的基本协议;
  2. 文件传输(TFTP 简单文件传输协议);
  3. 远程登录(Telnet),提供远程访问其它主机功能,它允许用户登录 internet 主机,并在这台主机上执行命令;
  4. 网络管理(SNMP 简单网络管理协议),该协议提供了监控网络设备的方法, 以及配置管理,统计信息收集,性能管理及安全管理等;
  5. 域名系统(DNS),该系统用于在 internet 中将域名及其公共广播的网络节点转换成 IP 地址。
传输层:

提供应用程序间的通信。其功能包括:一、格式化信息流;二、提供可靠传输。为实现后者,传输层协议规定接收端必须发回确认,并且假如分组丢失,必须重新发送。

网络层 :

负责相邻计算机之间的通信。其功能包括三方面。
一、处理来自传输层的分组发送请求,收到请求后,将分组装入IP数据报,填充报头,选择去往信宿机的路径,然后将数据报发往适当的网络接口。

二、处理输入数据报:首先检查其合法性,然后进行寻径–假如该数据报已到达信宿机,则去掉报头,将剩下部分交给适当的传输协议;假如该数据报尚未到达信宿,则转发该数据报。

三、处理路径、流控、拥塞等问题。

网络接口层:

这是 TCP / IP 软件的最低层,负责接收 IP 数据报并通过网络发送之,或者从网络上接收物理帧,抽出 IP 数据报,交给 IP 层。

专业名词解释

IP地址

每个计算机必须有一个 IP 地址才能够连入因特网。每个 IP 包必须有一个地址才能够发送到另一台计算机。常使用的 IP 地址是一个 32bit 的数字,也就是我们常说的 IPv4 标准,这 32bit 的数字分成四组,也就是常见的 255.255.255.255 的样式。

IP 路由器

当一个 IP 包从一台计算机被发送,它会到达一个 IP 路由器。IP 路由器负责将这个包路由至它的目的地,直接地或者通过其他的路由器。

域名

12 个阿拉伯数字很难记忆。使用一个名称更容易。当你键入一个像 http://www.baidu.com 这样的域名,域名会被一种 DNS 程序翻译为数字。

TCP/IP

TCP 负责应用软件(比如你的浏览器)和网络软件之间的通信。IP 负责计算机之间的通信。
TCP 负责将数据分割并装入 IP 包,然后在它们到达的时候重新组合它们。IP 负责将包发送至接受者。

Socket

Socket 是对 TCP / IP 协议的封装,像创建 Socket 连接时,可以指定使用的传输层协议,Socket 可以支持不同的传输层协议( TCP 或 UDP ),当使用 TCP 协议进行连接时,该 Socket 连接就是一个 TCP 连接。

TCP报文格式

请添加图片描述
不多解释,自行百度

连接(握手)

三次握手

三次握手

  1. TCP 服务器进程先创建传输控制块 TCB,时刻准备接受客户进程的连接请求,此时服务器就进入了 LISTEN(监听)状态;

  2. TCP 客户进程也是先创建传输控制块 TCB,然后向服务器发出连接请求报文,这是报文首部中的同部位 SYN=1,同时选择一个初始序列号 seq=x ,此时,TCP 客户端进程进入了 SYN-SENT(同步已发送状态)状态。TCP 规定,SYN 报文段(SYN=1的报文段)不能携带数据,但需要消耗掉一个序号。

  3. TCP 服务器收到请求报文后,如果同意连接,则发出确认报文。确认报文中应该 ACK=1,SYN=1,确认号是 ack=x+1,同时也要为自己初始化一个序列号 seq=y,此时,TCP 服务器进程进入了 SYN-RCVD(同步收到)状态。这个报文也不能携带数据,但是同样要消耗一个序号。

  4. TCP客户进程收到确认后,还要向服务器给出确认。确认报文的 ACK=1,ack=y+1,自己的序列号 seq=x+1,此时,TCP 连接建立,客户端进入 ESTABLISHED(已建立连接)状态。TCP 规定,ACK 报文段可以携带数据,但是如果不携带数据则不消耗序号。

  5. 当服务器收到客户端的确认后也进入 ESTABLISHED 状态,此后双方就可以开始通信了。

断开(挥手)

四次握手

四次挥手
7. 客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为 seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入 FIN-WAIT-1(终止等待1)状态。TCP 规定,FIN 报文段即使不携带数据,也要消耗一个序号。

  1. 服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号 seq=v,此时,服务端就进入了 CLOSE-WAIT(关闭等待)状态。TCP 服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个 CLOSE-WAIT 状态持续的时间。

  2. 客户端收到服务器的确认请求后,此时,客户端就进入 FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)

  3. 服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为 seq=w,此时,服务器就进入了 LAST-ACK(最后确认)状态,等待客户端的确认。

  4. 客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是 seq=u+1,此时,客户端就进入了 TIME-WAIT(时间等待)状态。注意此时 TCP 连接还没有释放,必须经过 2∗ *∗MSL(最长报文段寿命)的时间后,当客户端撤销相应的 TCB 后,才进入 CLOSED 状态。

  5. 服务器只要收到了客户端发出的确认,立即进入 CLOSED 状态。同样,撤销 TCB 后,就结束了这次的 TCP 连接。可以看到,服务器结束 TCP 连接的时间要比客户端早一些。

UDP (用户数据报协议)

UDP

无连接

UDP 无连接,时间上不存在建立连接需要的时延。空间上,TCP 需要在端系统中维护连接状态,需要一定的开销。此连接装入包括接收和发送缓存,拥塞控制参数和序号与确认号的参数。UCP 不维护连接状态,也不跟踪这些参数,开销小。空间和时间上都具有优势。

举个例子:
DNS 如果运行在 TCP 之上而不是 UDP,那么 DNS 的速度将会慢很多。
HTTP 使用 TCP 而不是 UDP,是因为对于基于文本数据的 Web 网页来说,可靠性很重要。
同一种专用应用服务器在支持 UDP 时,一定能支持更多的活动客户机。

无阻塞

UDP 没有拥塞控制,应用层能够更好的控制要发送的数据和发送时间,网络中的拥塞控制也不会影响主机的发送速率。某些实时应用要求以稳定的速度发送,能容 忍一些数据的丢失,但是不能允许有较大的时延(比如实时视频,直播等)

不可靠

UDP 提供尽最大努力的交付,不保证可靠交付。所有维护传输可靠性的工作需要用户在应用层来完成。没有 TCP 的确认机制、重传机制。如果因为网络原因没有传送到对端,UDP 也不会给应用层返回错误信息

面向报文

UDP 是面向报文的,对应用层的报文,添加首部后直接交付给 IP 层,既不合并,也不拆分,保留这些报文的边界。对 IP 层交上来 UDP 用户数据报,在去除首部后就原封不动地交付给上层应用进程,报文不可分割,是 UDP 数据报处理的最小单位。
正是因为这样,UDP 显得不够灵活,不能控制读写数据的次数和数量。比如我们要发送 100 个字节的报文,我们调用一次 sendto 函数就会发送 100 字节,对端也需要用 recvfrom 函数一次性接收 100 字节,不能使用循环每次获取 10 个字节,获取十次这样的做法。

数据量小

UDP 常用一次性传输比较少量数据的网络应用,如 DNS,SNMP 等,因为对于这些应用,若是采用 TCP,为连接的创建,维护和拆除带来不小的开销。UDP 也常用于多媒体应用(如 IP 电话,实时视频会议,流媒体等)数据的可靠传输对他们而言并不重要,TCP 的拥塞控制会使他们有较大的延迟,也是不可容忍的

UDP 广播

广播 UDP 与单播 UDP 的区别就是 IP 地址不同,广播使用广播地址 255.255.255.255,将消息发送到在同一广播网络上的每个主机。值得强调的是:本地广播信息是不会被路由器转发。当然这是十分容易理解的,因为如果路由器转发了广播信息,那么势必会引起网络瘫痪。

UDP 多播

多播,也称为“组播”,将网络中同一业务类型主机进行了逻辑上的分组,进行数据收发的时候其数据仅仅在同一分组中进行,其他的主机没有加入此分组不能收发对应的数据。

多播的优点:
  1. 具有同种业务的主机加入同一数据流,共享同一通道,节省了带宽和服务器的优点,具有广播的优点而又没有广播所需要的带宽。
  2. 服务器的总带宽不受客户端带宽的限制。由于组播协议由接收者的需求来确定是否进行数据流的转发,所以服务器端的带宽是常量,与客户端的数量无关。
  3. 与单播一样,多播是允许在广域网即 Internet 上进行传输的,而广播仅仅在同一局域网上才能进行。
组播的缺点:
  1. 多播与单播相比没有纠错机制,当发生错误的时候难以弥补,但是可以在应用层来实现此种功能。
  2. 多播的网络支持存在缺陷,需要路由器及网络协议栈的支持。
  3. 多播的应用主要有网上视频、网上会议等。

UDP 单播

单播的数据只是收发数据的特定主机进行处理

TCP和UDP的区别

  1. TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接。
  2. TCP提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达;UDP尽最大努力交付,即不保证可靠交付。
  3. TCP面向字节流,实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的。
    UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP电话,实时视频会议等)。
  4. 每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信。
  5. TCP首部开销20字节;UDP的首部开销小,只有8个字节。
  6. TCP的逻辑通信信道是全双工的可靠信道,UDP则是不可靠信道。

HTTP

HTTP是单向的,客户端发送请求,服务器发送响应。
举例来说,当客户端向服务器发送请求时,该请求以 HTTP 或 HTTPS 的形式发送,在接收到请求后,服务器会将响应发送给客户端。每个请求都与一个对应的响应相关联,在发送响应后客户端与服务器的连接会被关闭。每个 HTTP 或 HTTPS 请求每次都会新建与服务器的连接,并且在获得响应后,连接将自行终止。 HTTP 是在 TCP 之上运行的无状态协议,TCP 是一种面向连接的协议,它使用三向握手方法保证数据包传输的传递并重新传输丢失的数据包。

HTTP 与 TCP 的关系

  1. HTTP 协议的长连接和短连接,实质上是 TCP 协议的长连接和短连接。
  2. 每个 HTTP 连接完成后,其对应的 TCP 连接并不是每次都会关闭。从 HTTP/1.1起,默认使用长连接,用以保持连接特性。使用长连接的 HTTP 协议,会在响应头有加入这个头部字段:Connection:keep-alive
  3. 在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接。Keep-Alive 不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如 Apache,Nginx,Nginx 中这个默认时间是 75s)中设定这个时间。实现长连接要客户端和服务端都支持长连接。
    HTTP 属于应用层协议,在传输层使用 TCP 协议,在网络层使用 IP 协议。IP 协议主要解决网络路由和寻址问题,TCP 协议主要解决如何在 IP 层之上可靠的传递数据包,使在网络上的另一端收到发端发出的所有包,并且顺序与发出顺序一致。TCP 有可靠,面向连接的特点。

WebSocket

WebSocket 是双向的,在客户端-服务器通信的场景中使用的全双工协议,与 HTTP 不同,它以 ws:// 或 wss:// 开头。它是一个有状态协议,这意味着客户端和服务器之间的连接将保持活动状态,直到被任何一方(客户端或服务器)终止。在通过客户端和服务器中的任何一方关闭连接之后,连接将从两端终止。

HTTP 与 WebSocket 的异同点

  1. 建立在TCP之上,通过TCP协议来传输数据。
  2. 都是可靠性传输协议。
  3. 都是应用层协议。
  1. WebSocket是HTML5中的协议,支持持久连接,HTTP不支持持久连接
  2. HTTP是单向协议,只能由客户端发起,做不到服务器主动向客户端推送信息。

应用

RosBridge

ROSbridge 顾名思义,是一个ROS当中的中间件,ROS 桥,是用来和 java 语言进行通信的框架。
目前有三种通信方式,UDP、TCP、WebSocket。它通过 websocket 以 JSON 格式的 API 为非 ROS 环境提供 ROS 通信支持,
包括对 Topic,Service 的各种操作。这种通信方式相对于 rosjava 相比,代码量大大减少,轻量级、跨平台。
我们目前采用 WebSocket + UDP 形式实现。

Android

Android 采用主流网路库 OkHttp 简历 WebSocket 通道。

  1. 连接需要操控设备的局域网。
  2. 监听 UDP 广播信息,便获取 IP 地址。
  3. 通过 IP 地址建立 WebSocket,完成 Android 与 Ros 之间通信。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值